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(P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable 
for any Layer 2 VPN service reguiring P2MP connectivity over an IP or 
MPLS-enabled PSN. A P2MP PW established via the proposed mechanism 
is root initiated. This document updates RFC 7385 by reassigning the 
reserved value 0xFF to be the wildcard transport tunnel type. 
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1. Introduction 


A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 
attributes of a unidirectional P2MP Telecommunications service such 
as P2MP ATM over PSN. A major difference between a Point-to-Point 
(P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is 
intended for bidirectional service whereas the latter is intended for 
both unidirectional and, optionally, bidirectional service. 
Requirements for P2MP PWs are described in [RFC7338]. P2MP PWs can 
be constructed as either Single Segment Pseudowires (P2MP SS-PWs) or 
Multi-Segment Pseudowires (P2MP MS-PWs) as mentioned in [RFC7338]. 
P2MP MS-PW is outside the scope of this document. A reference model 
or a P2MP PW is depicted in Figure 1. A transport Label Switched 
Path (LSP) associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP 
(i.e., P2MP Traffic Engineering (TE) tunnel established via RSVP-TE 
[RFC4875] or P2MP LSP established via Multipoint LDP (mLDP) 
[RFC6388]) spanning from the Root PE (Provider Edge) to the Leaf 
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PE(s) of the P2MP SS-PW tree. For example, in Figure 1, PW1 can be 
associated with a P2MP TE tunnel or P2MP LSP setup using mLDP 
originating from PEl and terminating at PE2, PE3, and PE4. 


| <-------------- P2MP PW---------------- >| 
Native | | Native 
Service | |<--PSN1->| |<--PSN2->| | Service 
(AC) v V vV vV vV V (AC) 
4+----- + 4+------ + 4+------ + 
| | | | Pl |=========|T-PE2 |AC3 | +---+ 
| | | WE O > |-------- >|CE3 | 
Ml — | >| MAW 
| Wm PNL arado | +-————— + | 
| aas e] | rW 
| Wc ul | |=========| T-PE3 |AC4 | +---+ 
+---+  |AC1 ; | eboney BWÌ GO Heue > |-------- >|CE4 | 
| CE1|------- > |=========| | +---+ 
+---+ | | | +-----—- + +-----—- + | 
WEDD bo WM 
| | |=========| p2 |=========|T-PE4 |AC5 | +---+ 
| na BW DI GB EW aa > |-------- >|CE5| 
ma e [===] | 
4+----- + 4+------ + 4+------ + 


Figure 1: P2MP PW 


Mechanisms for establishing a P2P SS-PW using LDP are described in 
[RFC8077]. This document specifies a method of signaling P2MP PW 
using LDP. In particular, this document defines a new Forwarding 
Equivalence Class (FEC), TLVs, parameters, and status codes to 
facilitate LDP signaling and maintaining P2MP PWs. 


As outlined in [RFC7338], even though the traffic flow from a Root PE 
(R-PE) to Leaf PE(s) (L-PEs) is P2MP in nature, it may be desirable 
for any L-PE to send unidirectional P2P traffic destined only to the 
R-PE. The proposed mechanism takes such an option into 
consideration. 


The P2MP PW requires an MPLS LSP to carry the PW traffic, and the 


MPLS packets carrying the PW upstream label will be encapsulated 
according to the methods described in [RFC5332]. 
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2. Terminology 
2.1. Reauirements Language 


The key words "MUST", "MUST NOT", "REOUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 


BCP 14 


[RFC2119] [RFC8174] when, and only when, they appear in all 


capitals, as shown here. 


2.2. Abbreviations 


AGI: 


PE: 


PSN: 


PW: 


Attachment Group Identifier 


Customer Edge 

Forwarding Eguivalence Class 

Leaf PE (egress PE) 

Label Distribution Protocol 

Label Switched Path 

Multipoint Label Distribution Protocol (for P2MP/MP2MP LSP) 
Multi-Segment Pseudowire 

Point-to-Multipoint 

Point-to-Point 

Provider Edge 

Packet Switched Network 

Pseudowire 

Root PE (ingress PE, PE initiating P2MP PW setup) 
Switching Provider Edge (of MS-PW) 

Single-Segment Pseudowire 


Traffic Engineering 
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3. Signaling P2MP PW 


In order to advertise labels as well as exchange PW-related LDP 
messages, PES must establish LDP sessions among themselves. A PE 
discovers other PEs that are to be connected via P2MP PWs either via 
manual configuration or autodiscovery [RFC6074]. 


An R-PE and each L-PE MUST be configured with the same FEC as defined 
in Section 3.2. 


P2MP PW requires that there be an active P2MP PSN LSP set up between 


an R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN 
LSP is different depending on the signaling protocol used (RSVP-TE or 
mLDP). 


In the case of mLDP, a Leaf PE can decide to join the P2MP LSP at any 
time. In the case of RSVP-TE, the P2MP LSP is set up by the R-PE, 
generally at the initial service provisioning time. It should be 
noted that local policy can override any decision to join, add, or 
prune existing or new L-PEs from the tree. In any case, the PW setup 
can ignore these differences and simply assume that the P2MP PSN LSP 
is available when needed. 


P2MP PW signaling is initiated by the R-PE, which sends a separate 
P2MP PW LDP Label Mapping Message to each of the L-PE(s) belonging to 
that P2MP PW. This Label Mapping Message will contain the following: 


1. A FEC TLV containing a P2MP PW Upstream FEC Element that includes 
a Transport LSP sub-TLV. 


2. An Interface Parameters TLV, as described in [RFC8077]. 
3. A PW Group ID TLV, as described in [RFC8077]. 


4. A label TLV for the upstream-assigned label used by an R-PE for 
the traffic going from the R-PE to L-PE(s). 


The R-PE imposes the upstream-assigned PW label on the outbound 
packets sent over the P2MP PW; using this label, an L-PE identifies 
the inbound packets arriving over the P2MP PW. 
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Additionally, the R-PE MAY send Label Mapping Messages to one or more 
L-PEs to signal a unidirectional P2P PW(s). The L-PE(s) can use such 
a PW(s) to send traffic to the R-PE. This optional Label Mapping 
Message will contain the following: 


1. A P2P PW Downstream FEC Element 


2. A label TLV for the downstream-assigned label used by the 
corresponding L-PE to send traffic to the R-PE 


The LDP liberal label retention mode MUST be used; per reguirements 
specified in [RFC5036], the Label Reguest message MUST also be 
supported. 


The upstream-assigned label is allocated according to the rules in 
[RFC5331]. 


When an L-PE receives a PW Label Mapping Message, it MUST verify the 
associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP 
is not in place and its type is LDP P2MP LSP, the L-PE MUST attempt 
to join the P2MP LSP associated with the P2MP PW. If the associated 
P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the 
L-PE SHOULD wait till the P2MP transport LSP is signaled. If an L-PE 
fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW and 
MUST notify the user. In this case, a PW status message with status 
code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST 
also be sent to the R-PE. 


3.1. PW Ingress-to-Egress Incompatibility Issues 


If an R-PE signals a PW with a PW Type, Control Word (CW) mode, or 
interface parameters that a particular L-PE cannot accept, then the 
L-PE MUST NOT enable the PW and should notify the user. In this 
case, a PW status message with status code of 0x00000001 (Pseudowire 
Not Forwarding) MUST also be sent to the R-PE. 


Note that this procedure does not apply if the L-PE was not 
provisioned with this particular P2MP PW. In this case, according to 
the LDP liberal label retention rules, no action is taken. 


3.2. P2MP PW FEC 


[RFC8077] specifies two types of LDP FEC elements used to signal P2P 


PWs: "PWid FEC Element" and "Generalized PWid FEC Element". This 
document uses two FEC elements: "P2MP PW Upstream FEC Element" and 
"P2P PW Downstream FEC Element". These FEC elements are associated 


with a mandatory upstream-assigned label and an optional downstream- 
assigned label, respectively. 
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3.2.1. P2MP PW Upstream FEC Element 


The FEC type for the P2MP PW Upstream FEC Element is encoded as 
follows: 


0 L 2 3 
OEZ SA Sie. 2.58. 9 0: D 520030 A 455: 6. 18-9: 0.1.42: 38 2:67 9. 90:1 
+-4+-4-4-4+-4-4+-4-4-4-4-4+-4+-4-4-4-4+-4-4-4-4+-4-4-4-4+-4-4+-4-4-4-4-4-4 


|P2MP PW Up=0x82|C| PW Type | PW Info Length| 
4+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4- 4-4-4 -4- 4-4-4 + ++ 
| AGI Type | AGI Length | AGI Value 


+-+-4-4+-+-4+-4+-4+-+-4+-4+-+-4+-4+-+-+-4-4+-4-4-4+-4-4+-4-4+-4+-4+-4+-4-4+-4+-4-4+ 
AGI Value (contd.) E 


ed el 
| AII Type SAII Length | SAII Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
o SAII Value (contd.) E 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|PMSI Tunnel Typ|PMSI TT Length | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
+ + 


Transport LSP ID 
PER EE ET E E E RR E E. 
| Optional Parameters | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 2: P2MP PW Upstream FEC Element 
* P2MP PW Up: 
8-bit representation for the P2MP PW Upstream FEC type. 

x 'G.bits 


A value of 1 or 0 indicating whether a control word is present or 
absent for the P2MP PW. 


* PW Type: 


15-bit representation of PW Type as specified in [RFC8077]. 
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* 


PW Info Length: 


Sum of the AGI Length, SAII Length, PMSI Tunnel Type Length, and 
Optional Parameters fields in octets. If this value is 0, then it 
references all PWs using the specified group ID. In this case, 
there are neither other FEC element fields (AGI Type, SAII Value, 
etc.) present, nor any interface parameters TLVs. Alternatively, 
typed wildcard FEC described in Section 2.3, can be used to 
achieve the same or to have better filtering. 


AGI: 


An Attachment Group Identifier TLV can be used to uniguely 
identify a VPN or Virtual Private LAN Service (VPLS) instance 
associated with the P2MP PW. This has the same format as the 
Generalized PWid FEC Element [RFC8077]. 


SAII Value: 


A Source Attachment Individual Identifier is used to identify the 
root of the P2MP PW. The root is represented using AII Type 2 
format specified in [RFC5003]. Note that the SAII can be omitted 
by simply setting the length and type to zero. 


The P2MP PW is identified by the Source Attachment Identifier 
(SAI). If the AGI is non-null, the SAI is the combination of the 
SAII and the AGI, if the AGI is null, the SAI is the SAII. 


PMSI Tunnel Info: 


The PMSI Tunnel Info is the combination of the PMSI Tunnel Type, 
PMSI Tunnel Type Length (shown in the figure as PMSI TT Length), 
and Transport LSP ID fields. 


A P2MP PW MUST be associated with a transport LSP, which can be 
established using RSVP-TE or mLDP. 


PMSI Tunnel Type: 
The PMSI Tunnel Type is defined in [RFC6514]. 


When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a 
P2MP FEC Element as defined in [RFC6388]. The new mLDP Opague 
Value Element type for the L2VPN-MCAST application TLV (as 
specified in the IANA Considerations section (Section 7)) MUST be 
used. 
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* 


Transport LSP ID: 
This is the Tunnel Identifier that is defined in [RFC6514]. 


An R-PE sends a Label Mapping Message as soon as the transport LSP 
ID associated with the P2MP PW is known (e.g., via configuration) 
regardless of the operational state of that transport LSP. 


Similarly, an R-PE does not withdraw the labels when the 
corresponding transport LSP goes down. Furthermore, an L-PE 
retains the P2MP PW labels regardless of the operational status of 
the transport LSP. 


Note that a given transport LSP can be associated with more than 
one P2MP PW; in which case, P2MP PWs will be sharing the same R-PE 
and L-PE(s). An R-PE may also have many P2MP PWs with disjoint 
L-PE sets. 


In the case of LDP P2MP LSP, when an L-PE receives the Label 
Mapping Message, it can initiate the process of joining the P2MP 
LSP tree associated with the P2MP PW. 


In the case of RSVP-TE P2MP LSP, only the R-PE initiates the 
signaling of P2MP LSP. 


Optional Parameters: 


The Optional Parameter field can contain some TLVs that are not 
part of the FEC, but are necessary for the operation of the PW. 
This proposed mechanism uses two such TLVs: the Interface 
Parameters TLV and the PW Group ID TLV. 


The Interface Parameters TLV and PW Group ID TLV specified in 
[RFC8077] can also be used in conjunction with P2MP PW FEC in a 
label message. For the PW Group ID TLV, the sender and receiver 
of these TLVs should follow the same rules and procedures 
specified in [RFC8077]. For the Interface Parameters TLV, the 
procedure differs from the one specified in [RFC8077] due to 
specifics of P2MP connectivity. When the interface parameters are 
signaled by an R-PE, each L-PE must check if its configured 
value(s) is less than or egual to the threshold value provided by 
the R-PE (e.g., MTU size (Ethernet), max number of concatenated 
ATM cells, etc.). For other interface parameters, like CEP/TDM 
Payload Bytes, the value MUST exactly match the values signaled by 
the R-PE. 


Boutros & Sivabalan Standards Track [Page 9] 


RFC 8338 Root-Initiated P2MP Pseudowire March 2018 


A multicast traffic stream associated with a P2MP PW can be 
selective or inclusive. To support the former, this document 
defines a new optional Selective Tree Interface Parameter sub-TLV, 
as described in the IANA Considerations section (Section 7) and 
according to the format described in [RFC8077]. The value of the 
sub-TLV contains the source and the group for a given multicast 
tree, as shown in Figure 3. Also, if a P2MP PW is associated with 
multiple selective trees, the corresponding Label Mapping Message 
will carry more than one instance of this sub-TLV. Furthermore, 
in the absence of this sub-TLV, the P2MP PW is associated with all 
multicast traffic streams originating from the root. 


== iS eS Se Se SS + 
| Sub-TLV Type (1 Octet) | 
HT RES ee ee I AR + 
| Length (1 Octet) | 
"CA DD PCS SC II ee + 
| Multicast Source Length (1 Octet) | 
o a di + 
| Multicast Source (variable length) | 
toe ee Se oe GWA NE eee + 
| Multicast Group Length (1 Octet) 

A O O ea a + 
| Multicast Group (variable length) | 
A O O O O O + 


Figure 3: Selective Tree Interface Parameter Sub-TLV Value 
Note that since the LDP Label Mapping Message is only sent by the 


R-PE to all the L-PEs, it is not possible to negotiate any 
interface parameters. 
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3.2.2. P2P PW Downstream FEC Element 
The optional P2P PW Downstream FEC Element is encoded as follows: 
0 1 2 3 


0. 23:45:06: 1.8: 9001203 405060789 0/1203 456 7:89 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|P2P PWDown=0x84|C| PW Type | PW Info Length| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| AGI Type | Length | AGI Value 


+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+—>+>+>+—>+—>+>+—>+—+—+ 
7 AGI Value (contd.) f 
FAEN NN EE a 
| AII Type | Length | SAII Value 

+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>+—>+>+>+—>+—>+—>+—>+—+—+ 
e SAII Value (contd.) E 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 4: P2P PW Downstream FEC Element 


The definition of the fields in the P2P PW Downstream FEC Element is 
the same as those of P2MP PW Upstream FEC Element, shown in Figure 2. 


3.3. Typed Wildcard FEC Format for a New FEC 


[RFC5918] defines the general notion of a Typed Wildcard FEC Element; 
it requires FEC designers to specify a Typed Wildcard FEC Element for 
newly defined FEC element types. This document uses two FEC 
elements: "P2MP PW Upstream" and "P2P PW Downstream". Hence, 
definition of their Typed Wildcard format is required. 


[RFC6667] defines the Typed Wildcard FEC Element format for other PW 
FEC Element types (PWid and Generalized PWid FEC Element) in 
Section 3 as follows: 


0 1 2 3 
01,52 3:45 6.7.90 90:12 3.4 5.6: 79.9 0 2 34D: 6: 7.9.9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Typed Wcard-0x5|Type-PW FEC | Len = 3 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| ap? 1S 28 | PMSI Tun Type | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 5: Typed Wildcard Format for P2MP PW FEC Elements 
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[RFC6667] specifies that the Type field can be either the "PWid" 
(0x80) or "Generalized PWid" (0x81) FEC Element type. This document 
reuses the existing Typed Wildcard format specified in [RFC6667] and 
illustrated in Figure 5 and extends the definition of the Type field 
to also include the P2MP PW Upstream FEC Element and P2P PW 


Downstream FEC Element types. This document adds an additional field 
called the "PMSI Tunnel Type". This document reserves PMSI Tunnel 
Type OxFF to mean "wildcard transport tunnel type". The PMSI Tunnel 


Type field only applies to the Typed Wildcard P2MP PW Upstream FEC 
Element and MUST be set to "wildcard" for "P2P PW Downstream FEC 
Element" typed wildcard. 


3.4. Group ID Usage 


The PW Group ID TLV as defined in [RFC8077] contains a group ID 
capable of indicating an arbitrary group membership of a P2MP PW. 
This group ID can be used in LDP "wildcard" status and withdraw label 
messages, as described in [RFC8077]. 


3.5. Generic Label TLV 


As in the case of P2P PW signaling, P2MP PW labels are carried within 
the Generic Label TLV contained in the LDP Label Mapping Message. A 
Generic Label TLV is formatted and processed as per the rules and 
procedures specified in [RFC8077]. For a given P2MP PW, a single 
upstream-assigned label is allocated by the R-PE and is advertised to 
all L-PEs using the Generic Label TLV in Label Mapping Messages 
containing the P2MP PW Upstream FEC Element. 


The R-PE can also allocate a unigue label for each L-PE from which it 
intends to receive P2P traffic. Such a label is advertised to the 
L-PE using the Generic Label TLV and P2P PW Downstream FEC Element in 
Label Mapping Messages. 


4. LDP Capability Negotiation 


The capability of supporting P2MP PWs MUST be advertised to all LDP 
peers. This is achieved by using the methods in [RFC5561] to 
advertise the LDP P2MP PW Capability TLV. If an LDP peer supports 
the dynamic capability advertisement, this can be done by sending a 
new Capability message with the S bit set for the P2MP PW Capability 
TLV. If the peer does not support dynamic capability advertisement, 
then the P2MP PW Capability TLV MUST be included in the LDP 
Initialization message during session establishment. A Label 
Switched Router (LSR) having P2MP PW capability MUST recognize both 
the P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element in 
LDP label messages. 
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In line with reguirements listed in [RFC5561], the following TLV is 
defined to indicate the P2MP PW capability: 


0 il 2 3 
0. 20 3. A O AB 90.1, VA 3 Ay O 8 O 1. 52 3. A O FEBS 90 aL. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|U|F| P2MP PW Capability TLV | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|s| Reserved | Reserved | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 6: LDP P2MP PW Capability TLV 
AO U pits 
The Unknown bit [RFC5036] SHOULD be 1 (ignore if not understood). 
* pits 


The Forward unknown bit [RFC5036] SHOULD be O (don't forward if 
not understood). 


*  P2MP PW Capability TLV Code Point: 
The TLV type, which identifies a specific capability. Note that 
the P2MP PW Capability Code Point appears in the IANA 
Considerations section (Section 7). 

*. Swat: 
The State Bit indicates whether the sender is advertising or 
withdrawing the P2MP PW capability. The State bit is used as 


follows: 


1 - The TLV is advertising the capability specified by the P2MP PW 
Capability TLV Code Point. 


0 - The TLV is withdrawing the capability specified by the P2MP PW 
Capability TLV Code Point. 


* Length: 


MUST be set to 2 (octet). 
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5. P2MP PW Status 


In order to support the proposed mechanism, an LSR MUST be capable of 
handling PW status. As such, the PW status negotiation procedures 
described in [RFC8077] are not applicable to P2MP PW. An LSR MUST 
NOT claim to be P2MP PW capable by sending an LDP P2MP PW Capability 
TLV if it is not also capable of handling PW status. 


Once an L-PE successfully processes a Label Mapping Message for a 
P2MP PW, it MUST send appropriate PW status according to the 
procedure specified [RFC8077] to report the PW status. If no PW 
status notification is reguired, then no PW status notification is 
sent (for example, if the P2MP PW is established and operational with 
a status code of 0x00000000 (Success), a PW status message is not 
necessary). A PW status message sent from an L-PE to an R-PE MUST 
contain the P2P PW Downstream FEC Element to identify the PW. 


An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP 
PW state. Such a PW status message contains a P2MP PW Upstream FEC 
Element to identify the PW. 


Connectivity status of the underlying P2MP LSP that the P2MP PW is 
associated with can be verified using LSP ping and traceroute 
procedures described in [RFC6425]. 


6. Security Considerations 


In general, the security measures described in [RFC8077] are adeguate 
for this protocol. However, the use of MD5 as the method of securing 
an LDP control plane is no longer considered adeguately secure. 
Implementations should be written in such a way that they can migrate 
to a more secure cryptographic hash function when the next 
authentication method to be used in the LDP might not be a simple 
hash-based authentication algorithm. 


7. IANA Considerations 

7.1. FEC Type Name Space 
This document uses two FEC element types, 0x82 and 0x84, in the 
"Forwarding Eguivalence Class (FEC) Type Name Space" registry for the 


Label Distribution Protocol (LDP) [RFC5036]. IANA has added this 
document as a reference for the following entries: 


Value Hex Name Reference 
130 0x82 P2MP PW Upstream FEC Element [RFC8338] [RFC7358] 
132 0x84 P2P PW Downstream FEC Element [RFC8338] [RFC7358] 
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7.2. LDP TLV Type 


This document defines a new LDP TLV type in the "TLV Type Name Space" 
registry [RFC5036]. IANA has assigned the following value: 


TLV Type Description 
0x0703 P2MP PW Capability TLV 
7.3. mLDP Opaque Value Element TLV Type 


IANA has assigned a new mLDP Opaque Value Element Type in the "LDP MP 
Opaque Value Element basic type" registry [RFC6388] as follows: 


TLV Type Description 


3 L2VPN-MCAST application TLV 
Length: 4 
Value: A 32-bit integer, unigue in the context of the 


root, as identified by the root's address. 
7.4. Selective Tree Interface Parameter Sub-TLV Type 


IANA has assigned a sub-TLV from the "Pseudowire Interface Parameters 
Sub-TLV type Registry" [RFC4446] as follows: 


TLV Type Description 


0x1B Selective Tree Interface Parameter 
7.5. Wildcard PMSI Tunnel Type 


IANA has modified an entry in the "P-Multicast Service Interface 
Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border 


Gateway Protocol (BGP) Parameters" registry [RFC7385]. Value OxFF, 
which was previously marked as "Reserved", has been updated as 
follows: 

Value Meaning Reference 

OxFF wildcard transport tunnel type [RFC8338] 
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